perm filename LISP.BUG[BUG,LSP]18 blob
sn#713505 filedate 1983-06-04 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00081 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00012 00002 BUG-LISP and LISP-FORUM
C00013 00003 ∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
C00014 00004 ∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
C00017 00005 ∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
C00018 00006 ∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
C00020 00007 ∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00022 00008 ∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
C00024 00009 ∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
C00027 00010 ∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
C00030 00011 ∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
C00031 00012 ∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
C00033 00013 ∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
C00035 00014 ∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
C00037 00015 ∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
C00038 00016 ∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
C00040 00017 ∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
C00042 00018 ∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
C00043 00019 ∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
C00044 00020 ∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
C00046 00021 ∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
C00048 00022 ∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
C00049 00023 ∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
C00052 00024 ∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
C00053 00025 ∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
C00054 00026 ∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
C00055 00027 ∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
C00057 00028 ∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
C00058 00029 ∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
C00059 00030 ∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
C00060 00031 ∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
C00062 00032 ∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
C00064 00033 ∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
C00065 00034 ∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
C00066 00035 ∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
C00068 00036 ∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
C00070 00037 ∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
C00071 00038 ∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
C00072 00039 ∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
C00073 00040 ∂17-Sep-82 1701 GSB@MIT-ML previous patch
C00075 00041 ∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
C00077 00042 ∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
C00079 00043 ∂29-Oct-82 1519 Alan Bawden <ALAN at MIT-MC> [TONYH: forwarded] (bug-PROGRAM??????)
C00083 00044 ∂29-Oct-82 1702 JONL at PARC-MAXC Your recent note on MacLisp errors
C00096 00045 ∂31-Oct-82 1132 TONYH at MIT-AI
C00101 00046 ∂31-Oct-82 1308 George J. Carrette <GJC at MIT-MC> lossage after lossage
C00104 00047 ∂01-Nov-82 1417 David Eppstein <CSD.Kronj at SU-SCORE> SUBFORK module (LEDIT)
C00109 00048 ∂03-Nov-82 2158 JONL at PARC-MAXC 4th level indirection -- maybe you haven't yet seen this?
C00112 00049 ∂20-Nov-82 1508 GJC at MIT-MC FLAME warning: Scheme broken on OZ today.
C00116 00050 ∂20-Nov-82 1932 David C. Plummer <DCP at MIT-MC> Re: Scheme broken on OZ today.
C00124 00051 ∂21-Nov-82 2357 Martin David Connor <MARTY at MIT-MC> A minor update for Top-20 Maclisp
C00140 00052 ∂19-Dec-82 1947 JONL at PARC-MAXC Re: (\ x 0) revisited, revisited, revisited
C00142 00053 ∂19-Dec-82 2023 Glenn S. Burke <GSB at MIT-ML> Re: Re: (\ x 0) revisited, revisited, revisited
C00146 00054 ∂26-Dec-82 1917 PB e-subjob communication
C00148 00055 ∂08-Jan-83 1147 EB @ MIT-MC
C00149 00056 ∂11-Jan-83 1506 EB @ MIT-MC
C00150 00057 ∂21-Jan-83 1441 JOSHM at MIT-OZ How do I...
C00151 00058 ∂21-Jan-83 1448 JOSHM at MIT-OZ at MIT-MC How do I...
C00152 00059 ∂21-Jan-83 1850 Feinberg@CMU-CS-C How do I...
C00156 00060 ∂14-Feb-83 2041 Communications Satellite <COMSAT @ MIT-MC> Msg of Monday, 14 February 1983 20:12 EST
C00158 00061 ∂05-Apr-83 1711 Alan Bawden <ALAN @ MIT-MC> buglisphack@sail
C00159 00062 ∂05-Apr-83 1911 George J. Carrette <GJC @ MIT-MC> LOOP macro expansions into LET
C00161 00063 ∂05-Apr-83 2251 David C. Plummer <DCP@SCRC-TENEX> LOOP macro expansions
C00163 00064 ∂07-Apr-83 0125 Alan Bawden <ALAN @ MIT-MC>
C00164 00065 ∂07-Apr-83 0234 Alan Bawden <ALAN@MIT-OZ> I though we fixed this?
C00166 00066 ∂08-Apr-83 2325 Alan Bawden <ALAN @ MIT-MC> Gratuitous optimization
C00167 00067 ∂11-Apr-83 2051 Kent M. Pitman <KMP @ MIT-MC>
C00169 00068 ∂11-Apr-83 2052 Kent M. Pitman <KMP @ MIT-MC>
C00170 00069 ∂11-Apr-83 2323 Pandora B. Berman <CENT @ MIT-ML> file migrated
C00172 00070 ∂13-Apr-83 2209 Dave Touretzky at CMU-CS-A CMU MacLisp broken
C00174 00071 ∂17-Apr-83 1349 PASIEKA@MIT-OZ Pretty-Printer
C00178 00072 ∂18-Apr-83 2004 WILLIS@MIT-ML
C00180 00073 ∂18-Apr-83 2117 Kent M. Pitman <kmp at MIT-MC> WILLIS@ML's TYO gripe
C00181 00074 ∂18-Apr-83 2129 Alan Bawden <ALAN @ MIT-MC> IMAGE mode IO
C00196 00075 ∂11-May-83 0928 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
C00198 00076 ∂11-May-83 0931 @USC-ECL,@MIT-MC:MOON@SCRC-TENEX LOOP CONTINUE STATEMENT
C00201 00077 ∂11-May-83 1022 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
C00203 00078 ∂14-May-83 1416 @USC-ECL,@MIT-MC:KMP@MIT-OZ <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
C00207 00079 ∂14-May-83 1632 @USC-ECL:KMP@MIT-MC
C00209 00080 ∂15-May-83 0920 @USC-ECL,@MIT-MC:GJC@MIT-MC <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
C00212 00081 ∂26-May-83 2214 @USC-ECL,@MIT-MC:ALAN@MIT-OZ Yuch!
C00214 ENDMK
C⊗;
BUG-LISP and LISP-FORUM
∂20-Aug-82 2041 George J. Carrette <GJC at MIT-MC> fixes to maclisp
Date: 20 August 1982 23:27-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: fixes to maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Can you tell us the best way to assemble a Maclisp on a tops-20
so that we can put in the various accumulated fixes in the version
on OZ? For example, the MT fix to suspend. Thanks.
∂21-Aug-82 1157 John Ruttenberg <Ruttenberg at YALE> Bug in setf and arraycall
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Bug in setf and arraycall
To: Bug-Lisp at MIT-MC
Seems to be a problem with push and arraycall. Here's the source file:
(defvst bug-st
(a = (*array () t 10))
)
(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
(defun bug (self member index)
(push member (bug-st-ai self index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
And here's how Maclisp takes it:
Yale Haclisp 82 (in Maclisp 2088)
> (defvst bug-st
(a = (*array () t 10))
)
;Loading DEFVST 3
;Loading EXTMAC 183
;Loading ERRCK 20
;Loading VECTOR 64
;Loading DEFVSX 85
BUG-ST
>(defmacro bug-st-ai (self index)
`(arraycall t (bug-st-a ,self) ,index))
BUG-ST-AI
>(defun bug (self member index)
(push member (bug-st-ai self index)))
BUG
>(setq b (cons-a-bug-st))
#{BUG-ST A #T-10-71712}
>(bug b 'a 4)
(A)
>(bug b 'a 4)
;G0017 UNBOUND VARIABLE
;BKPT UNBND-VRBL
> (baktrace)
BAKTRACE
+INTERNAL-UBV-BREAK← ARRAYCALL← PUSH← BUG←
It seems especially odd to me that things should blow up only after the
second call to bug.
-------
∂21-Aug-82 1207 Jonathan Rees <Rees at YALE> (SSTATUS SYNTAX #/| ...)
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
To: Bug-Lisp at MIT-MC
Subject: (SSTATUS SYNTAX #/| ...)
Cc: Ellis at YALE, Ruttenberg at YALE
Trying to set the syntax of | doesn't work.
(SSTATUS SYNTAX #/| 2.) ;2 is syntax of %, :, etc.
2
'|
/↑T
Vertical bars in symbols read as control-T's.
∂22-Aug-82 1558 Alan Bawden <ALAN at MIT-MC> (SSTATUS SYNTAX #/| ...)
Date: 22 August 1982 18:59-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: BUG-LISP at MIT-MC, Ellis at YALE, Ruttenberg at YALE
Date: Saturday, 14 August 1982 00:31-EDT
From: Jonathan Rees <Rees at YALE>
(SSTATUS SYNTAX #/| 2.)
2
'|
/↑T
This is because (SSTATUS SYNTAX) doesn't know enough to set up the character
translation when it turns off a macro character. You can either do (SSTATUS
CHTRAN #/| #/|) immediately afterwords, or use (SETSYNTAX #/| 2. #/|) instead.
I started to fix this, but the code is too ugly to be believed.
∂22-Aug-82 1647 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 22 August 1982 19:29-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: BUG-LISP at MIT-MC
cc: Ruttenberg at YALE
Date: 14-Aug-82 10:55AM-EDT (Sat)
From: John Ruttenberg <Ruttenberg at YALE>
It seems especially odd to me that things should blow up only after the
second call to bug.
A smaller case of the bug:
(defvst bug-st
(a = (*array () t 10))
)
(defun bug (self member index)
(push member (arraycall t (bug-st-a self) index)))
(setq b (cons-a-bug-st))
(bug b 'a 4)
(bug b 'a 4)
After the first call to BUG it's definition has been changed to be:
(defun bug (self member index)
(push member (arraycall t <gensym> index)))
This is probably an artifact of PUSH being a fexpr (but thinking like a macro),
bug it also seems to depend heavily on the source of the array being a defvst
accessor. It doesn't happen if you are using defstruct instead. Perhaps those
responsible for defvst/push will step forward and fix?
∂22-Aug-82 1923 John Ruttenberg <Ruttenberg at YALE> Re: push/defvst interaction?
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
Subject: Re: push/defvst interaction?
To: Alan at MIT-MC
Cc: Bug-Lisp at MIT-MC
In-Reply-To: Bawden's message of 22 August 1982 19:29-EDT
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
-------
∂23-Aug-82 0001 George J. Carrette <GJC at MIT-MC> push/defvst interaction?
Date: 23 August 1982 02:45-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: ALAN at MIT-MC, BUG-LISP at MIT-MC
As a bit of honest practical advice, I would concur with ALAN in
suggesting that you use DEFSTRUCT in preference to DEFVST.
The story goes like this: DEFVST was supposed to be part of
a package of code which was "NILCOM," common to both NIL and Maclisp,
and presumably to be part of "common-lisp." As it turned out though,
the implementation of all of that "NILCOM" code was too tentative
and kludgy to be worth bringing up in actual VAX NIL, so instead
code like Defstruct (which is de-facto common-lisp)
was brought up. So you see, there can be little
incentive here (at MIT) to support/fix-bugs in code such as DEFVST.
On the other hand, it is quite easy for me to make available to
you an option to defstruct called "EXTEND" which does the same
job as "DEFVST" except that the interface is a lot cleaner,
and it actually works! (It is what RLB and I used last summer to
cross-compile NIL from the pdp-10 to the VAX). You can get it
by FTPing "GJC;SFIX FASL" from the MIT-MC machine. Source is in
"GJC;SFIX >" on MIT-MC.
To answer your question about source code: The most up-to-date
versions of things are on the LIBDOC, LSPSRC, and NILCOM directories
on MIT-MC. The *best* solution seems to be to keep a winning
Maclisp environment working on MIT-OZ, and let people FTP
stuff from there.
-gjc
∂23-Aug-82 1409 Alan Bawden <ALAN at MIT-MC> push/defvst interaction?
Date: 23 August 1982 17:03-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: push/defvst interaction?
To: Ruttenberg at YALE
cc: BUG-LISP at MIT-MC
Date: 22-Aug-82 10:22PM-EDT (Sun)
From: John Ruttenberg <Ruttenberg at YALE>
It doesn't happen if you are using defstruct instead.
We would use defstruct, except that using it into named hunks
makes it want to use some version of defvst that we don't have
here. Where are the authorative up to date sources for things
like defstruct and defvst? I'd like to know if we can get
this fix and others like it.
I heve never released a version of defstruct that had anything whatsoever to do
with ANY of the out-of-core (autoloading) MacLisp libraries. There is a
feature that made defstruct a front end for defvst which I have never released
to anyone, but that wouldn't do you any good anyway. Can you send me an
example of a defstruct that tries to load ANYTHING? Up-to-date defstruct FASL
can be found on LISP;STRUCT FASL.
Also note that I don't seem to be able to compile the bug infested
code. (Same problem - some unbound gensym in the push expression).
I'm not surprised that you can't compile it either.
∂24-Aug-82 1545 Glenn S. Burke <GSB at MIT-ML> distribution request
Date: 24 August 1982 18:40-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: distribution request
To: TY at MIT-ML
cc: BUG-LISP at MIT-ML
tar@MIT-ML (Sent by ←←←036@MIT-ML) 08/24/82 14:48:02 Re: Phone message
Steve Cadrak called.
Academic Computing Center
University of Vermont
Burlington, VT 05405
He would like to obtain the latest MACLISP. (He has version 2009)
TOPS-20 version 5.
(802) 656-3910
∂24-Aug-82 1939 Greg Skinner <EE.GDS at MIT-OZ> Lisp problem
Date: 24 Aug 1982 2050-EDT
From: Greg Skinner <EE.GDS at MIT-OZ>
Subject: Lisp problem
To: bug-lisp at MIT-OZ
Subject: LISP problem
Is this a bug or just a feature? (especially (gcd 15 5)
evaluating to 1, while the others seem to evaluate correctly).
Plus, is there any way that LISP can be set so that base 10
numbers are echoed as such? (re 8 = 10 and 10 = 10)
[PHOTO: Recording initiated Tue 24-Aug-82 8:37PM]
TOPS-20 Command processor 4(661)-2
@lisp
LISP 2129
Alloc? n
*
(gcd 15 5)
1
(gcd 30 10)
10
(gcd 8 4)
4
(gcd 60 30)
30
(gcd 50 5)
5
(quotient 50 4)
12
50
50
(quit)
@pop
[PHOTO: Recording terminated Tue 24-Aug-82 8:38PM]
-------
∂24-Aug-82 1939 Barry Margolin at MIT-MULTICS Re: Lisp problem
Date: 24 August 1982 20:56 edt
From: Barry Margolin at MIT-MULTICS
Subject: Re: Lisp problem
Sender: Margolin.Multics at MIT-MULTICS
To: Greg Skinner <EE.GDS at MIT-OZ>
cc: bug-lisp at MIT-OZ
In-Reply-To: Message of 24 August 1982 20:50 edt from Greg Skinner
There were no bugs displayed in that session. By default, Maclisp is in
base 8, and 15(8) = 13(10) (where the notation xx(n) means the numeral
xx in base n), and the GCD of 5(10) and 13(10) is indeed 1. The
variables that control the base that numbers are input and output in are
"base", which is the base that numbers are output in, and "ibase", which
controls the input base. Associated with these is the variable
"*nopoint", which if set to T causes the decimal point that normally
follows decimal numbers on output to be suppressed. Note that any
fixnum that has a trailing decimal point (as in 100.) is also read in in
decimal, regardless of the setting of ibase, so to initially set the
base variables you should say:
(setq base 10.)
(setq ibase 10.)
∂27-Aug-82 1306 Glenn S. Burke <GSB at MIT-ML> (SSTATUS SYNTAX #/| ...)
Date: 27 August 1982 15:51-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (SSTATUS SYNTAX #/| ...)
To: Rees at YALE
cc: Ellis at YALE, Ruttenberg at YALE, BUG-Lisp at MIT-MC
I believe that SETSYNTAX is what you want here; it assumes that the
choices (bits only, MACRO, SPLICING) are mutually exclusive. (sstatus
syntax ...) only hacks the syntax bits. In obscure applications this
is actually useful (the fact that it doesn't clobber the macro/chtran
entry, that is), because you can do strange and perverse things with
something like "." so that it is still decimal point but also acts
like a special-token (implemented as a reader macro). (I've done this.
It almost works.)
∂29-Aug-82 2313 GSB@MIT-ML new format installed on MC and OZ
From: GSB@MIT-ML
Date: 08/30/82 01:34:11
Subject: new format installed on MC and OZ
GSB@MIT-ML 08/30/82 01:34:11 Re: new format installed on MC and OZ
To: (BUG LISP) at MIT-ML
format 827 has been put on MC and OZ. the file types involved are
FASL, BRACK, FLOAT, NUM, and UMACS. This fixes a fencepost bugs
in ~$ and a misfeature in operator definition via define-format-op,
and maybe some other things which i have since forgotten.
∂30-Aug-82 1613 JonL at PARC-MAXC Re: fixes to maclisp
Date: 30 Aug 1982 16:10 PDT
From: JonL at PARC-MAXC
Subject: Re: fixes to maclisp
In-reply-to: GJC's message of 20 August 1982 23:27-EDT
To: George J. Carrette <GJC at MIT-MC>
cc: JONL at MIT-MC, BUG-LISP at MIT-MC
I've just returned from two weeks travelling (LispConference, AAAI, MIT
visit etc) and I didn't see you at MIT -- are you still there?
There used to be a .CTL file on MIT-XX, PS:<MACLISP>ASSLIS.CTL, which
you could just SUBMIT and it would doo all the rest. It would leave
an *uninitialized* result on SS:<MACLISP>BBLISP.EXE.<nnnn> and also
do an initialization phase leaving PS:<MACLISP>XLISP.EXE.<nnnn> and
PS:<MACLISP>LISP.SYMBOLS.<nnnn>. You then rename XLISP to LISP after
certifying that things are winning. The value of the uninitialized
file is that it's hard to patch the LISP.EXE file with the existing NDDT since
it involves changing file page accessibilities (read-only etc).
∂30-Aug-82 2236 Kent M. Pitman <KMP at MIT-MC> FORMAT losing
Date: 31 August 1982 01:15-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Sender: VP at MIT-MC
Subject: FORMAT losing
To: GSB at MIT-MC
cc: BUG-LISP at MIT-MC
In Maclisp 2122, Format 827. on MIT-MC:
Ignoring the rough points in what these actually ask FORMAT to do ('cuz
there are a few conceptual bugs), these functions do not behave in ways
even remotely resembling what the LispM does with them. For example, the
LispM does not err, pdl-overflow, or complain of missing ~]'s. Simple
tests like (f nil), (f '(a)), (f '(a b)), (f '(a b c)) and likewise for g
should give you a feel for what I'm talking about. G'luck.
(defun f (x)
(lexpr-funcall #'format t "~#[nothing~;~S~;~S and ~S~
~:;~@{~<~% ~1,50:;~#[~1; and~] ~S~>~↑,~}~]" x))
(defun g (x)
(format t "~%;; ~{~<~%;; ~1,50:;~#[~1; and~] ~S~>~↑,~}.~%" x))
-kmp
∂31-Aug-82 2102 Glenn S. Burke <GSB at MIT-MC>
Date: 31 August 1982 23:57-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on OZ,
∂31-Aug-82 2107 Glenn S. Burke <GSB at MIT-MC>
Date: 1 September 1982 00:00-EDT
From: Glenn S. Burke <GSB at MIT-MC>
To: BUG-LISP at MIT-MC
on oz, an LH/| page disappears when the job is suspended and restarted.
One gets a memory protection violation...
∂31-Aug-82 2310 George J. Carrette <GJC at MIT-MC> hacking/assembly maclisp
Date: 1 September 1982 02:04-EDT
From: George J. Carrette <GJC at MIT-MC>
Subject: hacking/assembly maclisp
To: JONL at MIT-MC
cc: BUG-LISP at MIT-MC
Thanks for the info, now, I wonder if I have *read* access to the
Maclisp directory on XX? sigh... it is a wonder anything gets done
at MIT inside LCS. Yes, I expected to be at the lisp conference,
but when the time came to leave it seemed more fun to stay at
ATARI and hack up some demo's in NIL on their brand-new 780.
I heard that some of the graphics in TRON were done in Maclisp
on a Foonly (by the way). Remember that bug note/question about
extened objects and arithmetic some months ago? I think it
was from the same guy, Craig Renolds?
Anyway, thats the state of things, I'll be at ATARI again in a little
while and I'll give you a call in Palo Alto, want to see some
3-D graphics in NIL controlled via the flavor system?
[No, I didn't implement a number-compiler for NIL yet, the crunching
stuff is written in (sigh) "C" which gets interfaced to NIL in the
obvious way.]
-gjc
∂01-Sep-82 1043 Robert P. Krajewski <RpK at MIT-ML> WITH-OPEN-FILE
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Subject: WITH-OPEN-FILE
To: BUG-Lisp at MIT-MC
cc: RpK at MIT-OZ
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
``Bob''
∂01-Sep-82 1333 Kent M. Pitman <KMP at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:27-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: WITH-OPEN-FILE
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
There is a package on LIBLSP called IOTA which does what you want. I'm working
on a library of macros and functions to help people trying to hack Lisp
Machine compatibility. Among things in that library will be WITH-OPEN-FILE.
For now, though, IOTA is the thing to use. It's used heavily in lots of Maclisp
systems and works fine. Documentation is in LIBDOC;IOTA >
-kmp
∂01-Sep-82 1403 Alan Bawden <ALAN at MIT-MC> WITH-OPEN-FILE
Date: 1 September 1982 16:56-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: WITH-OPEN-FILE
To: RpK at MIT-ML
cc: BUG-LISP at MIT-MC, RpK at MIT-OZ
Date: 1 September 1982 13:40-EDT
From: Robert P. Krajewski <RpK at MIT-ML>
Does WITH-OPEN-FILE exist in MacLisp ? It would be a very nice
thing to have. I'd define a robust version of it, but I don't
know how MacLisp does UNWIND-PROTECTs and such. (If you take
out the clean-up code, it's very simple.)
MacLisp does UNWIND-PROTECT by having an UNWIND-PROTECT special form just like
the LispMachine's. There is no built-in WITH-OPEN-FILE macro, but clearly you
can write your own using UNWIND-PROTECT, or wait until KMP writes one (he'll
think of some screws you never dreamed of I'll bet) or you can convert your
code to using IOTA.
This may be a stupid question, but why don't the objects
returned by OPEN accept messages like :TYO, :TYI, :STRING-OUT,
:LINE-OUT, :TRUENAME, and so on ? All they seem to accept are
very general messages that would be handled by the Lisp Machine
SI:VANILLA-FLAVOR -- :PRINT-SELF and others.
I don't understand this question in the least. The objects returned by OPEN
don't except ANY messages. They are not message recieving objects. They do
have a printed representation, but that isn't accomplished by sending any
messages. You don't do I/O by sending them messages, but by calling functions
like PRINC and TYO and passing them the "file object" as an argument.
∂01-Sep-82 1958 Glenn S. Burke <GSB at MIT-MC> renamef failure
Date: 1 September 1982 22:52-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: renamef failure
To: BUG-LISP at MIT-MC
the IOJRST at RENAM5+6 should be a JFCL. If the RNAMF fails then the
file has been closed but the jfn not released. The IOJRST after the
failing CLOSF will clobber the first error message (and probably not
allow the error to return because iojrst stack hacks probably aren't
additive). I have changed this in the source, someone patch it on
a 20?
∂01-Sep-82 2045 FEINBERG at CMU-20C renamef failure
Date: 1 September 1982 23:36-EDT (Wednesday)
From: FEINBERG at CMU-20C
To: Glenn S. Burke <GSB at MIT-MC>
Cc: BUG-LISP at MIT-MC
Subject: renamef failure
Howdy!
It is patched on OZ.
--Chiron
∂01-Sep-82 2227 Kent M. Pitman <KMP at MIT-MC>
Date: 2 September 1982 01:19-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: RPK at MIT-MC
cc: BUG-LISP at MIT-MC
I put a package on LIBLSP; (and <LIBLSP> on OZ) called LISPM. Please play
with this and tell me if it gives you any troubles. If no one reports any
bugs in a week or two, I'll announce it to INFO-MACLISP. The file defines
compatibility definitions for DEFSUBST, DOLIST, DOTIMES, MEXP, WITH-OPEN-FILE
and WITH-OPEN-STREAM. Documentation is in LIBDOC;LISPM > and in
OZ:PS:<LIBLSP>LISPM.LSP
-kmp
∂06-Sep-82 1540 Devon S. McCullough <Devon at MIT-ML>
Date: 6 September 1982 18:39-EDT
From: Devon S. McCullough <Devon at MIT-ML>
To: BUG-lisp at MIT-OZ
In lisp in Remote-File 14.0, LMFILE-Remote 18.0, MIT-Specific 10.0,
System 87.19, Experimental ZMail 46.3, microcode 164, No, devon,
on Lisp Machine One:
In the blue manual on page 158, 11.1 describing closures, it says
The form (closure var-list function), where var-list is a list of...
...
the value cells of the symbols. Then function is applied to the ARGUMENT. (This...
in the next-to last paragraph on the page. ARGUMENT should be plural, or I'm mixed up!
∂06-Sep-82 1544 Kent M. Pitman <KMP at MIT-MC>
Date: 6 September 1982 18:38-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: BUG-LISP at MIT-MC
I forwarded DEVON's bug report to BUG-LISPM where it should have gone.
∂06-Sep-82 1827 Robert Elton Maas <REM at MIT-MC> (LISTEN)
Date: 6 September 1982 21:20-EDT
From: Robert Elton Maas <REM at MIT-MC>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
Why does (LISTEN) take about 100 miliseconds (0.1 second) to execute?
This seems to be a very long time.
∂07-Sep-82 1329 Glenn S. Burke <GSB at MIT-ML> (LISTEN)
Date: 7 September 1982 16:07-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (LISTEN)
To: BUG-LISP at MIT-MC
i replied to REM
∂07-Sep-82 1737 Glenn S. Burke <GSB at MIT-MC> suspend tty code fix (tops-20 vts)
Date: 7 September 1982 18:46-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: suspend tty code fix (tops-20 vts)
To: BUG-LISP at MIT-MC
cc: mt at MIT-OZ
According to MT, the problem is that Lisp is setting a whole
word with stmod rather than only the left half as it should;
this can be fixed by making it do RTMOD, and then HLL 2,TI.ST6
rather than the MOVE it now does, at OPNT2+twentysome.
This has been fixed in the source, and patched into the BBLISP on OZ.
We made a .EXE, but did not install it on <SUBSYS> yet (it was in use).
∂07-Sep-82 1738 Skef Wholey <Wholey at CMU-20C> Complr's losing lossage, of course
Date: Tuesday, 7 September 1982 20:14-EDT
From: Skef Wholey <Wholey at CMU-20C>
To: Bug-Complr at MIT-MC
Subject: Complr's losing lossage, of course
Let's see what complr does with the following code:
-----
;;; -*- Lisp -*-
;;;
;;; COMPLR LOSSAGE!!!
;;;
(defconst const-1 0)
(defconst const-2 3)
(defmacro combine-somehow (a b)
`(deposit-byte ,b 28 4 ,a))
(defun fleep ()
(print (combine-somehow const-1 const-2))
(print (combine-somehow const-2 const-1))
(print (combine-somehow 0 3))
(print (combine-somehow 3 0)))
-----
When compiled, (fleep) prints the following:
3
0
3
805306368
Seems a little bogus, huh?
[I realize that no one does much MacLisp maintainence these days, but I just
needed someone to flame at...]
--Skef
∂07-Sep-82 2221 Glenn S. Burke <GSB at MIT-MC> load-byte/deposit-byte miscompilation
Date: 8 September 1982 00:55-EDT
From: Glenn S. Burke <GSB at MIT-MC>
Subject: load-byte/deposit-byte miscompilation
To: Wholey at CMU-20C
cc: BUG-COMPLR at MIT-MC
I have identified the problem in the source, but not tested or
installed the fixes yet (get to it tomorrow). There were a
couple things wrong. Stay tuned...
∂09-Sep-82 0021 GSB@MIT-ML previous patch, to OPNT2
From: GSB@MIT-ML
Date: 09/09/82 03:20:05
Subject: previous patch, to OPNT2
GSB@MIT-ML 09/09/82 03:20:05 Re: previous patch, to OPNT2
To: (BUG LISP) at MIT-ML
is incorrect. I'll publicize the correction when i stop being shafted
by losing hardware, and when i go over it with a Travers
∂13-Sep-82 1324 Kent M. Pitman <KMP at MIT-MC>
Date: 13 September 1982 16:18-EDT
From: Kent M. Pitman <KMP at MIT-MC>
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML
It's sort of a bug in Autokeep (or maybe in Twenex) that you can't set
the Autokeep bit for an entire cluster of files and have it apply to new
versions when written. I think what happened is that when Glenn wrote the
patch the other night to fix SUSPEND lossage, he didn't set the autokeep
bit back on. This was not so much an issue of OZ policy or anything silly
like that as just an easy slip to have happen. This is yet another good
reason why <SUBSYS>MACLISP should probably be an unchanging .EXE file
which does nothing more than reload some other file (such as <MACLISP>'s
MACLISP.EXE). I think this is what is done on EE and I think the reasons
are similar. In any case, sorry for your lost work. It was not intended
that it shouldn't be kept.
-kmp
∂14-Sep-82 1102 Jonathan Alan Solomon <JSol at USC-ECLC>
Date: Tuesday, 14 September 1982 10:52-PDT
From: Jonathan Alan Solomon <JSol at USC-ECLC>
To: David C. Plummer <DCP at MIT-MC>
Cc: ALAN at MIT-MC, BUG-LISP at MIT-MC, bug-oz at MIT-OZ, gsb at MIT-ML,
KMP at MIT-MC
Address: 3737 South Hoover Street Room PHE 204
Los Angeles, California 90089-0273
Phone: (213) 202-1793
Yes for V5, If you save a <SYSTEM>EXEC.EXE properly with this switch
set it will remain set for everyone. Individual users who want to
change it can simply unset it in their COMAND.CMD files.
In my exec there already exists a command to override the file
setting. People seem to be doing SET FILE (no) EPHEMERAL and (no)
AUTOKEEP at random and whenever they feel like it. If you INSTALL LISP
SYS:LISP.EXE AUTOKEEP NO CONFIRM you will *always* get a Kept lisp no
matter what anyone does to the file (this is in my exec under v4).
--JSol
∂14-Sep-82 2252 Stavros M. Macrakis <MACRAK at MIT-MC> < WNA msg
Date: 15 September 1982 01:50-EDT
From: Stavros M. Macrakis <MACRAK at MIT-MC>
Subject: < WNA msg
To: BUG-LISP at MIT-MC
(< 4.5 3)
;4.5 fixnum cant compare to flonum
args=4.5
(return '(4))
...still unhappy...
(return '(3.4))
...happy...
∂17-Sep-82 1643 Glenn S. Burke <GSB at MIT-ML> (status ttysize) on 20X
Date: 17 September 1982 19:44-EDT
From: Glenn S. Burke <GSB at MIT-ML>
Subject: (status ttysize) on 20X
To: ALAN at MIT-MC
cc: BUG-lisp at MIT-MC
Fixed in the source, STATUS 259 (hohoho). The sign bit is used for
(status terpri) on a per-file basis, and things like LINEL and this
code have to be careful to use magnitude only. I will patch this in
on OZ and XX shortly.
(sstatus terpri t [file]) sets this; it is probably being done by something
you load up.
∂17-Sep-82 1658 GSB@MIT-ML (status ttysize) bug, 20x
From: GSB@MIT-ML
Date: 09/17/82 19:46:34
Subject: (status ttysize) bug, 20x
GSB@MIT-ML 09/17/82 19:46:34 Re: (status ttysize) bug, 20x
To: (BUG LISP) at MIT-ML
i should have said, STTYS1+1 should use MOVM rather than MOVE.
∂17-Sep-82 1701 GSB@MIT-ML previous patch
From: GSB@MIT-ML
Date: 09/17/82 19:57:35
Subject: previous patch
GSB@MIT-ML 09/17/82 19:57:35 Re: previous patch
To: (BUG LISP) at MIT-ML
well it's patched in the bblisp on oz.
The scheme dump shares with lisp on the wrong dir so i can't replace
the <maclisp> copy, and XX is wedged in such a way that i can only
get in via telnet which seems to interpret <cr> as <lf> in nddt.
∂01-Oct-82 0404 Kent M. Pitman <KMP at MIT-MC> More data
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP at MIT-MC>
Subject: More data
To: BUG-LISP at MIT-MC
cc: JPG at MIT-MC
Well, my feeling is that people shouldn't rely on the exact truth value
which comes back from a true/false predicate. Sad that it ws documented
like that.
By the way, here's some more data. There seems to be a pattern:
Arg1 Arg2 Return Value
A AB T
AB ABC T
ABC ABCD T
ABCD ABCDE T
ABCDE ABCDEF LESSP
ABCDEF ABCDEFG T
ABCDEFG ABCDEFGH T
ABCDEFGH ABCDEFGHI T
ABCDEFGHI ABCDEFGHIJ T
ABCDEFGHIJ ABCDEFGHIJK LESSP
ABCDE ABCDEFG LESSP
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
∂02-Oct-82 1234 Alan Bawden <ALAN at MIT-MC> ALPHALESSP: More data
Date: 2 October 1982 15:31-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: ALPHALESSP: More data
To: BUG-LISP at MIT-MC, JPG at MIT-MC, KMP at MIT-MC
Date: 1 October 1982 07:01-EDT
From: Kent M. Pitman <KMP>
Looks like when the characters match exactly up to the length of the first
symbol and the second symbol's pname continues on, the symbol LESSP is
returned. Pretty odd.
The fix is to patch the MOVEI D,QLESSP at ALPHAL to be MOVE D,VT.ITY
It only seems to matter whether D contains NIL or non-NIL except that the
contents of D get returned in the special case that JPG discovered.
∂29-Oct-82 1519 Alan Bawden <ALAN at MIT-MC> [TONYH: forwarded] (bug-PROGRAM??????)
Date: 29 October 1982 18:17-EDT
From: Alan Bawden <ALAN at MIT-MC>
Subject: [TONYH: forwarded] (bug-PROGRAM??????)
To: BUG-LISP at MIT-MC
Date: 29 October 1982 17:56-EDT
From: TONYH at MIT-AI
To: BUG-PROGRAM at MIT-AI
I have three little problems which defy all of the info we have here.
If anyone can offer any help or suggestions we'd be very grateful.:
(1) Macros which are compiled in one file cannot be called from
another file if the latter is also compiled. The error message is
MACRO NOT PERMITTED IN UUO CALL. We think it must be something to
do with the declarations made at the tops of files for the compiler's
sake, but we have no information about them, and all our guesses based on
MacLisp source files have failed;
(2) We have tried to make the tilde a special readmacro. The idea is that special
comments within a file (they're quoted strings) should be prefaced by the tilde,
and that when the file is loaded the readmacro will place these comments
into a HELP system. The file containing the readmacro definition is
compiled, and the idea works well as long as the files subsequently loaded
(those with the tilde-ised comments in) are not compiled. The readmacro won't
work on FASL files , including its own file.
Also, does anyone happen to know how to stop typed-in characters from
being echoed back to the terminal? I'm trying to build alittle keypad-
driven editor, but my keypad (VT52) sends three characters at once,
which I'd rather not see!
Oh - I've just remembered another one. Our MacLisp occasionally has fits
of GC←DAEMON errors involving STRING-COMPRESS-SPACE, and frankly none of
us can understand the source code which might tell us why...
Many thanks in advance to anyone who can help, from the very heart of
quaint little old England.
Tony.
∂29-Oct-82 1702 JONL at PARC-MAXC Your recent note on MacLisp errors
Date: 29 OCT 1982 1700-PDT
From: JONL at PARC-MAXC
Subject: Your recent note on MacLisp errors
To: TONYH at MIT-AI
cc: BUG-LISP at MIT-MC
Your questions (1) and (2) arise from misunderstanding how and
when macros are applied (both readmacros and interpreter/compiler
macros).
1) Macros are never "called" in the sense that we think of calling
a funciton -- they are "expanded" by the interpreter and compiler,
but of course if they are not available to the compiler when compiling
some file, then no expansion can be done, and the compiler will defaultly
assume that the unknown name stands for a function call (rather than for
some macro to be expanded).
2) when READing a file, the s-expressions are stored as ascii text, and
the readmacro characters are invoked when such character is encountered
by the READer; FASL files, on the contrary, store either the
compiled versions of programs, or a special internal-format for other
s-exressions. Perhaps a reasonable approach is for the tilde macro
merely to append to some global list, which is then output near the end of
your file. Thus both ascii files being READ and compile dFASL files would
have a consistent representation of what is wanted in the HELP system (namely,
the list of goodies which was produced by READing the ffile in the first place).
As for deletion of the echo, it will depend on what kind of system you are using
TOPS10 or TOPS20. If the latter, you can turn of echoing by an appropriate STATUS
call which sets the bits in the TOPS20 echocontrol words; There may be some explanation
of this (i.e., the extended STATUS calls for TOPS20) in the note which I used to
attach to the distributed MacLisp tapes.
As for the GCDAEMON reported errors, it sounds like you have a copy of the STRING
package from early to mid 1980. Many bugs in it were fixed in late 1980 and
very early 1981, so these problems should go away if you can get the current
distribution (which was supposed to have taken place just as I was leaving MIT
in mid March of this year.)
More hints on problems (1) and (2)
Thus usual procedure for using "compiled" macros is to seperate them out
into a file by themselves, and have them loaded into the compiler each time
you compile some file which might use some of them. Admittedly this is not quite
as nice as defining the macros where they might "naturally" occur, but . . .
Suppose you have your tilede macro collect some data into TILDELIST. Then at the
end of the file you could put a form
(SETQ DATASTUFF '#.TILDELIST)
this wouold be one way of insureing that DATASTUFF would have the save value after
loading the FASL file as when loading thee source file.
∂31-Oct-82 1132 TONYH at MIT-AI
Date: 31 October 1982 13:05-EDT
From: TONYH at MIT-AI
To: BUG-LISP at MIT-AI
Dear JONL -
Thank you very much for your help. Unfotunatley, in trying to make
use of it ZI seem to have made things worse, to such an extent that the system
itself pleaded with me to call you again. I'd better show you what I'm
doing - you'll probably see at a glance what horrors I'm perpetrating on your
long-suffering MacLisp:
(declare (SETQ DEFMACRO-FOR-COMPILING 'T DEFMACRO-DISPLACE-CALL 'T)
(special helplist))
;;; During loading, the tilde (~) readmacro allows the special comments
;;; in this file to be stored for later access by the APROPOS function.
;;; On the property-list of 'HELP, under the property 'COMMENTS, will
;;; be found a list of the comments, each element being a dotted pair
;;; of the unquoted part of the comment and the quoted part.
(eval-when (compile load)
(and (status feature COMPLR)
(own-symbol DEFREADMACRO /~-readmacro))) ;superstition...
(eval-when (eval load compile)
(setq helplist nil)
(defmacro defreadmacro (char &rest body)
(let ((macro-name (symbolconc char '-readmacro)))
(setsyntax char 'macro macro-name)
`(defun ,macro-name () ,.body)))
(defreadmacro /~
(let* ((/↑q t) (comment `(,(read) ,[atsign](read))))
(push comment helplist)
t)))
[atsign] intended to represent the symbol on this machine!
Then follows the comment itself:
~MSG "Simple formatter..."
...and the function it is supposed to describe - also a macro. Then,
a line I added in the belief that it was the kind of thing you were advising:
(putprop 'help '#.helplist 'comments)
That's the end of the file. I then tried to compile it:
;BKPT DATA So I did:
$p
(COMMENT **ERROR** #75526 Unrecognizable datum ←← Collecatoms in function FOO)
; %%%%%%%%%%%%%%%%%%%%COMPILER ERRO(R - CALL JONL%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
;BKPT BARF
Ugh, what have I done? Sorry to bother you with this again so soon. I would
have flogged on with it on my own except for what the machine said just there.
As to your other valuable help - yes, I had just about reached the same
conclusion regarding how to re-use "compiled" macros. I just hoped,
(we are riddled with superstition here) that there might be a clever way
around the problem. We seem to have the May '82 version of STRING, but
I'll check that the dates are right. And Lord alone knows what happened
to any notes you included with the source tapes - such things go
through many administrative hands before reaching poor hackers like us!
Thank you again, anyway.
Tony.
∂31-Oct-82 1308 George J. Carrette <GJC at MIT-MC> lossage after lossage
Date: 31 October 1982 16:04-EST
From: George J. Carrette <GJC at MIT-MC>
Subject: lossage after lossage
To: TONYH at MIT-AI
cc: BUG-LISP at MIT-MC
It doesn't help to be superstitious about Maclisp. In fact, it helps a lot
to keep things as simple as possible, not using a feature unless you
really understand what it is doing. Here is what I recommend:
(1) In one file, put your "compile-time" environment. This includes
macros and readmacros, and special declarations, e.g.
(herald macros)
(defvar helplist)
(defun help-comment-readmacro ()
(push (cons (read) (read)) helplist))
(setsyntax #/~ 'macro 'help-comment-readmacro)
(defmacro helplist-begin ()
(setq helplist ())
(defmacro helplist-end ()
`(defprop help ,helplist comments))
;; Note that I didn't bother with defining a fancy DEFREADMACRO, since
;; it just isn't worth the trouble.
(2) Then your source-file would look like :
(eval-when (eval compile)
(or (get 'macros 'version) (load "macrofile")))
(helplist-begin)
.... stuff stuff stuff ...
(helplist-end)
(3) Do not use the Maclisp string package. It is has proven to
be completely unreliable. An alternative, which has been used in a text
editor written in maclisp, is in "GJC;CHAR >" on MIT-MC.
Someday a reasonable string may be released as part of the Maclisp
distribution, until then you should be able to get by fine with
something like "GJC;CHAR >"
Note that this file should be loaded at COMPILE and RUNTIME,
since it includes declarations, readmacros, and code.
-gjc
∂01-Nov-82 1417 David Eppstein <CSD.Kronj at SU-SCORE> SUBFORK module (LEDIT)
Date: 1 Nov 1982 0055-PST
From: David Eppstein <CSD.Kronj at SU-SCORE>
Subject: SUBFORK module (LEDIT)
To: Bug-LISP at MIT-MC
The lines in SI:GIVUP-TTYINTS that set the inferior fork's capabilities
are switched, so that the fork gets no caps, causing LEDIT to lose big.
Old code:
(jsys #.EPCAP handle
(boole 2 1←18 cap←inferior)
(boole 2 1←18 cap←poss←inf)
1)
Correct code:
(jsys #.EPCAP handle
(boole 2 1←18 cap←poss←inf)
(boole 2 1←18 cap←inferior)
1)
David
-------
∂03-Nov-82 2158 JONL at PARC-MAXC 4th level indirection -- maybe you haven't yet seen this?
Date: 3 NOV 1982 2058-PST
From: JONL at PARC-MAXC
Subject: 4th level indirection -- maybe you haven't yet seen this?
To: info-lisp at MIT-AI, info-lispm at MIT-AI
cc: gls at MIT-AI, rpg at MIT-MC
Date: 3 Nov. 1982 1:49 pm PST (Wednesday)
From: Treichel.PA
Subject: Lisp Song
To: CIS↑
Reply-To: Treichel
Have you seen this?
Jeanie
---------------------------
Date: 3 Nov. 1982 4:23 pm EST (Wednesday)
From: Gafter.Henr
Subject: LISP song
To: AllWhimsy↑.pa, Language↑, Gottwald, KAnderson
cc: Gafter
This was in the uucp bboard net.jokes recently.
-------------------------------------------------------
From decvax!utzoo!utcsrgv!roderick Mon Nov 1 14:24:35 1982
Another Glitch in the Call
------- ------ -- --- ----
(Sung to the tune of a recent Pink Floyd song.)
We don't need no indirection
We don't need no flow control
No data typing or declarations
Hey! Did you leave the lists alone?
Chorus:
All in all, it's just a pure-LISP function call.
We don't need no side effect-ing
We don't need no scope control
No global variables for execution
Hey! Did you leave those args alone?
(Chorus)
We don't need no allocation
We don't need no special nodes
No dark bit-flipping in the functions
Hey! Did you leave the bits alone?
(Chorus)
We don't need no compilation
We don't need no load control
No link edit for external bindings
Hey! Did you leave that source alone?
(Chorus, and repeat)
------------------------------------------------------------
∂20-Nov-82 1508 GJC at MIT-MC FLAME warning: Scheme broken on OZ today.
Date: Saturday, 20 November 1982 18:03-EST
Sender: GJC at MIT-OZ
From: GJC at MIT-MC
To: GLR at MIT-OZ
Cc: BUG-LISP at MIT-OZ, FEINBERG at MIT-OZ, GJS at MIT-OZ, HAL at MIT-OZ,
HANSON at MIT-OZ, RWK at SCRC
Subject: FLAME warning: Scheme broken on OZ today.
In-reply-to: The message of 20 Nov 1982 15:43-EST from GLR
You would patch Maclisp without knowing who was doing maintenance and
where the canonical sources are? Sigh...
As of now there is no Local Maclisp maintenance, and no canonical sources.
When OZ came up I was to install Maclisp here from sources on MC and XX,
but instead MARTY cleverly arranged for people outside of MIT and the LAB to
"help him out" thereby contributing to the present inconsistent mess.
However, things seemed to run anyway, so it wasn't worth hassling, considering
the amount of other work to do on other projects.
On the other hand, when I try to run SCHEME on OZ to verify examples run
in other implementations (in this case on the VAX), I don't like to end up
spending lots of time hassling MACLISP and lack of DISK SPACE on OZ.
(Who ?designed? the present disk-structure settup here anyway?
With all those RP06's, why are we losing? Doesn't anybody GFR?)
If you have problems with Maclisp on TOPS-20, first try to get around
them by loading LISP-LEVEL stuff, and dumping out your own version using SHARE.
The mere fact that you had INTERLOCK problems with trying to patch LISP.EXE
should have told you that somebody was depending on it.
The present problem is just that the most experienced Maclisp user/implementor
people here at the labs don't find it worthwhile to fix maclisp bugs in
the MIDAS sources. Mainly because they are responsible for or depend on
stable large systems in the present versions of Maclisp, and because they
have new implementations of lisp systems to work on.
To push forward the maclisp world for the sake of small changes is
conterproductive, as a small time spent by inexperienced hackers
can force the spending of considerable time by experienced hackers.
This is a very expensive form of MAKE-WORK. (Real $$$ expensive too.)
-GJC
p.s. In other words. Cool it for a while in the Maclisp directory.
After the Thanksgiving break you can talk with GSB, myself, and others
about what changes are really needed.
∂20-Nov-82 1932 David C. Plummer <DCP at MIT-MC> Re: Scheme broken on OZ today.
Date: 20 November 1982 22:25-EST
From: David C. Plummer <DCP at MIT-MC>
Subject: Re: Scheme broken on OZ today.
To: RWK at SCRC-TENEX
cc: GJC at MIT-MC, GLR at MIT-OZ, FEINBERG at MIT-OZ, HAL at MIT-OZ,
GJS at MIT-OZ, HANSON at MIT-OZ, BUG-LISP at MIT-OZ
You want to make separate code and data spaces for the current
MACLISP, do you?? Well, FORGET IT!!! Perhaps you should get
Gorin's book on TWENEX assembler and read the section on extended
addressing.
Basically, CAR and CDR won't work. Well, it might have a prayer
if the CODE for CAR and CDR were in the DATA section. This goes
for all other code that does a CAR or CDR. Well, then again, you
might be able to get around that by making CAR and CDR be two
instructions instead of one. The second instruction would set
the left half to be the DATA section. Kludge, kludge, kludge.
Now what about all those other primitive LISP operators??
That is not the right solution. The right solution is to
reimplement 'Lisp' for extended addressing machines. For 2060's
this would give you 31 address spaces (assuming you can't do much
useful stuff in section 0). On the Jupiter I think the number
jumps to 4095 (and then all you need is several dozen disk drives
for paging).
I know of at least one effort to write an extended addressing
superset of Common Lisp. How much MACLisp code will need to be
modified or rewritten probably depends on how well it was written
for portability in the first place.
My feable knowledge of Common Lisp forces me to make the
following warnings:
* Expect your programs to get bigger. CONSes will take up two
words instead of one.
* Fixnums may shrink to 32 (or even 30) bits. Overflow will cons
bignums.
* Expect arithmetic operations to slow down. I think Common Lisp
does generic arithemetic. If so, a simple + on non-declared
numbers needs to check the arguments and value (even in compiled
code).
∂21-Nov-82 2357 Martin David Connor <MARTY at MIT-MC> A minor update for Top-20 Maclisp
Date: 22 November 1982 02:46-EST (Monday)
Sender: MARTY at MIT-OZ
From: Martin David Connor <MARTY at MIT-MC>
To: GSB at ML
Subject: A minor update for Top-20 Maclisp
Cc: Bug-Lisp at MC
I found the following in MC:L;STATUS >
Specifically in the (sstatus ttyint ... ) code:
...
SSTIN1: HRRM B,(TT)
...
IFN D20,[
POP P,TT ;RESTORE TTSAR
ROT F,1 ;RESTORE CHARACTER
CAIE F,3 ;DON'T ALLOW USE TO ASSIGN ↑C
==> CAILE F,26. ;TOPS-20 ONLY SUPPORTS TO ↑Z
| JRST UNLKTRUE ;RETURN TRUE, BUT DON'T DO TELL THE OP SYS
| ...
|
= Well, this perhaps used to be true, but is no longer. these days,
one can assign several other characters.
I think the update I would suggest is to remove the test altogether,
since the bit values for the interrupt word on the 20 after the
altmode would have to be special cased.
For my particular application I need to get control at interrupt
I made myself a patched lisp until this is changed, and I indeed am
able to get the altmode interrupt properly.
∂19-Dec-82 1947 JONL at PARC-MAXC Re: (\ x 0) revisited, revisited, revisited
Date: 19 DEC 1982 1945-PST
From: JONL at PARC-MAXC
Subject: Re: (\ x 0) revisited, revisited, revisited
To: ALAN at MIT-MC
cc: BUG-LISP at MIT-MC, GSB at MIT-ML, JONL
In response to your message sent 19 December 1982 21:00-EST
It has always been the case that MacLisp's "single-character"
arithmetic functions were driven by the desire for open-compilation.
Thus one gives up any interpreter error checking in the compiled
code, merely accepting what the hardware returns. It's certainly
no surprise, then, that the PDP10 does odd things with division by
zero -- or do I mistake the tone of your note?
By the bye, I had to bring in the generic operation, since the
"right" thing for the \ subr to do is to cause an error when
given a 0 divisor (just as it would if you gave it NIL for an arg);
unfortunately, this may not be the right thing to do to "fix" the
REMAINDER function: see the caveat in my previous msg.
∂19-Dec-82 2023 Glenn S. Burke <GSB at MIT-ML> Re: Re: (\ x 0) revisited, revisited, revisited
Date: 19 December 1982 23:20-EST
From: Glenn S. Burke <GSB at MIT-ML>
Subject: Re: Re: (\ x 0) revisited, revisited, revisited
To: jonl at PARC-MAXC
cc: BUG-lisp at MIT-MC
No, the whole point of this proposal is that the "right" thing to do
is not to cause an error for a zero divisor, but to check for that
and "do the right thing". This is predicated on the premise that for
the REMAINDER operation, a 0 divisor has a defined result.
(Presumably someone else once thought this, given that the REMAINDER
function has this check.)
The \ function is not an interface to the second value returned by the
IDIV instruction. Our semantics are just that the interpreted version
will behave compatibly with the compiled one. If it takes an extra
couple of instructions to do it right, then great. (HAULONG takes a
couple instructions, as do some of the fix-float conversions.)
∂26-Dec-82 1917 PB e-subjob communication
To: BUG-e, BUG-lisp
What happens when a subjob has lots of output for a window that you are not
looking at? If, as I assume, it suspends the job once some small buffer
is filled, this is a lose, since I often want to get a bunch of output while
doing something else. Or am I wrong, and I can do that?
∂08-Jan-83 1147 EB @ MIT-MC
Date: Saturday, 8 January 1983 14:36-EST
Sender: EB @ MIT-OZ
From: EB @ MIT-MC
To: Bug-Lisp @ MIT-OZ
Does OZ have the latest Maclisp? Lisp 2129, which is installed there,
still has the bug wherein it opens JFNs in restricted mode.
∂11-Jan-83 1506 EB @ MIT-MC
Date: Tuesday, 11 January 1983 13:46-EST
Sender: EB @ MIT-OZ
From: EB @ MIT-MC
To: Bug-Lisp @ MIT-OZ
There is no ALARMCLOCK function in Lisp 2129 on Oz. Is the lack of
ALARMCLOCK permanent?
∂21-Jan-83 1441 JOSHM at MIT-OZ How do I...
Date: 21 Jan 1983 1737-EST
From: JOSHM at MIT-OZ
Subject: How do I...
To: info-lisp at MIT-OZ
cc: bug-lisp at MIT-OZ, bug-scheme at MIT-OZ, info-scheme at MIT-OZ
How do turn off input echoing from inside maclisp or scheme? I'm
writing a display oriented program and the typed input keeps destroying
the display.
-Josh
-------
∂21-Jan-83 1448 JOSHM at MIT-OZ at MIT-MC How do I...
Date: 21 Jan 1983 1737-EST
From: JOSHM at MIT-OZ at MIT-MC
Subject: How do I...
To: info-lisp at MIT-OZ at MIT-MC
cc: bug-lisp at MIT-OZ at MIT-MC, bug-scheme at MIT-OZ at MIT-MC,
info-scheme at MIT-OZ at MIT-MC
How do turn off input echoing from inside maclisp or scheme? I'm
writing a display oriented program and the typed input keeps destroying
the display.
-Josh
-------
∂21-Jan-83 1850 Feinberg@CMU-CS-C How do I...
Received: ID <FEINBERG@CMU-CS-C>; 21 Jan 83 21:43:21 EST
Date: 21 Jan 83 21:43:19 EST
From: Feinberg@CMU-CS-C
To: JOSHM%MIT-OZ@MIT-MC
Cc: bug-lisp%MIT-OZ@MIT-MC, bug-scheme%MIT-OZ@MIT-MC
Subject: How do I...
In-reply-to: The message of 21 Jan 1983 17:37-EST from JOSHM at MIT-OZ at MIT-MC
Hi.
Load <MACLISP>TTY.FASL, and use DO-WITH-TTY-OFF, like so:
(DO-WITH-TTY-OFF <form1> <form2> ... <formn>) ;Like a PROGN with echo
--Chiron
∂14-Feb-83 2041 Communications Satellite <COMSAT @ MIT-MC> Msg of Monday, 14 February 1983 20:12 EST
Received: from SRI-AI by SU-AI with NCP/FTP; 14 Feb 83 20:40:24 PST
Received: from MIT-MC.ARPA by SRI-AI.ARPA with TCP; Mon 14 Feb 83 18:27:43-PST
Date: 14 February 1983 21:02 EST
From: Communications Satellite <COMSAT @ MIT-MC>
Subject: Msg of Monday, 14 February 1983 20:12 EST
To: MacLisp @ SRI-AI
ReSent-date: Mon 14 Feb 83 20:38:37-PST
ReSent-from: MacLisp Hackers <MacLisp@SRI-AI.ARPA>
ReSent-to: buglisphack@SU-AI.ARPA
FAILED: BUGLISPHACK at SU-AI; Host appears to be permanently down or not accepting mail.
Failed message follows:
-------
Received: from SRI-AI.ARPA by SU-SCORE.ARPA with TCP; Mon 14 Feb 83 14:43:12-PST
Date: Mon 14 Feb 83 14:40:50-PST
From: MacLisp Hackers <MacLisp@SRI-AI.ARPA>
Subject: Re: I really don't know where to send this one...
To: NCP.EGK@SU-GSB-HOW.ARPA, Bug-Oz%mit-Oz@SU-SCORE.ARPA,
Bug-Lisp%MIT-Oz@SU-SCORE.ARPA, daniel%mit-Oz@SU-SCORE.ARPA,
Gumby%mit-Oz@SU-SCORE.ARPA
In-Reply-To: Your message of Sun 13 Feb 83 13:15:11-PST
There ISN'T a SYS:MACLISP.EXE on OZ!
-------
∂05-Apr-83 1711 Alan Bawden <ALAN @ MIT-MC> buglisphack@sail
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 17:11:14 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 17:08:35-PST
Date: 4 April 1983 14:12 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: buglisphack@sail
To: SAILBUGLISPHACK @ MIT-MC
I redirected all entries in our mailing lists file for buglisphack to
indirect through usc-ecl. You should start recieving bug-lisp (etc.) mail
again, and I should stop getting complaints from the mailer.
∂05-Apr-83 1911 George J. Carrette <GJC @ MIT-MC> LOOP macro expansions into LET
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 19:11:19 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 19:04:39-PST
Date: 5 April 1983 22:05 EST
From: George J. Carrette <GJC @ MIT-MC>
Subject: LOOP macro expansions into LET
To: DCP @ SCRC-TENEX
cc: BUG-LISP @ MIT-MC, BUG-LOOP @ MIT-ML, GSB @ MIT-ML,
BSG @ SCRC-TENEX, bug-Lispm @ SCRC-TENEX
In-reply-to: Msg of 5 Apr 1983 19:23-EST from DCP at SCRC-TENEX
In PDP-10 maclisp, if you wanted to take up GSB's suggestion, you
could have LET and LET* in the interpreter autoload "LIBLSP;LETFEX FASL"
which is an implementation of LET optimized for the interpreter,
it defines 'em as FEXPRs. Not only is it fast and cons no extra
storage, it is about 1/6 the size of the macro let implementation,
and comes with a money-back guarantee..
∂05-Apr-83 2251 David C. Plummer <DCP@SCRC-TENEX> LOOP macro expansions
Received: from USC-ECL by SU-AI with NCP/FTP; 5 Apr 83 22:51:05 PST
Received: from MIT-MC by USC-ECL; Tue 5 Apr 83 22:49:55-PST
Received: from SCRC-MYSTIC by SCRC-TENEX with CHAOS; Wed 6-Apr-83 01:11:38-EST
Date: Wednesday, 6 April 1983, 01:07-EST
From: David C. Plummer <DCP@SCRC-TENEX>
Subject: LOOP macro expansions
To: BUG-lisp@MIT-MC, bug-Lispm@SCRC-TENEX, BUG-LOOP@MIT-ML
Cc: BSG@SCRC-TENEX, GSB@MIT-ML
In-reply-to: The message of 5 Apr 83 19:23-EST from DCP at SCRC-TENEX
Small warning to those who put my suggestion in their private versions
of LOOP: Be sure to also get the EVAL-WHEN at the beginning of the file
that sets up all the features/non-features. Failure to do this will,
among other things, cause collection to fail on the LispM. I just found
this out the hard way...
∂07-Apr-83 0125 Alan Bawden <ALAN @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 7 Apr 83 01:25:01 PST
Received: from MIT-MC by USC-ECL; Thu 7 Apr 83 01:23:03-PST
Date: 7 April 1983 04:24 EST
From: Alan Bawden <ALAN @ MIT-MC>
To: BUG-LISP @ MIT-MC
Is LISP:LISP.SYMBOLS.2129 not the place I should expect to find the symbols
for MacLisp version 2129 currently running on OZ? They don't appear to be
correct.
∂07-Apr-83 0234 Alan Bawden <ALAN@MIT-OZ> I though we fixed this?
Received: from USC-ECL by SU-AI with NCP/FTP; 7 Apr 83 02:34:47 PST
Received: from MIT-MC by USC-ECL; Thu 7 Apr 83 02:30:24-PST
Date: Thu, 7 Apr 1983 05:17 EST
From: Alan Bawden <ALAN@MIT-OZ>
To: bug-lisp@MIT-OZ
Subject:I though we fixed this?
In my current lisp job on OZ:
(status ttysize)
(30 . -117)
Is this a "fixed in the source but not patched"?
∂08-Apr-83 2325 Alan Bawden <ALAN @ MIT-MC> Gratuitous optimization
Received: from USC-ECL by SU-AI with NCP/FTP; 8 Apr 83 23:25:33 PST
Received: from MIT-MC by USC-ECL; Fri 8 Apr 83 23:22:29-PST
Date: 9 April 1983 02:23 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: Gratuitous optimization
To: BUG-COMPLR @ MIT-MC
I note that < has an optimizer that causes (< 1 x 8) to compile as one might
expect, while in the interpreter this is an error....
∂11-Apr-83 2051 Kent M. Pitman <KMP @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 20:51:39 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 18:08:52-PST
Date: 11 April 1983 21:08 EST
From: Kent M. Pitman <KMP @ MIT-MC>
To: bagley @ MIT-OZ
cc: BUG-LISP @ MIT-MC
Use ((LMLIB) LISPM) for now. Some of that stuff will become autoloading
in a Lisp release soon, I think.
∂11-Apr-83 2052 Kent M. Pitman <KMP @ MIT-MC>
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 20:52:02 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 18:11:32-PST
Date: 11 April 1983 21:08 EST
From: Kent M. Pitman <KMP @ MIT-MC>
To: bagley @ MIT-OZ
cc: BUG-LISP @ MIT-MC
oops. i meant ((LIBLSP) LISPM).. sorry 'bout the confusion.
--kmp
∂11-Apr-83 2323 Pandora B. Berman <CENT @ MIT-ML> file migrated
Received: from USC-ECL by SU-AI with NCP/FTP; 11 Apr 83 23:23:42 PST
Received: from MIT-MC by USC-ECL; Mon 11 Apr 83 23:19:39-PST
Date: 12 April 1983 02:19 EST
From: Pandora B. Berman <CENT @ MIT-ML>
Subject: file migrated
To: bug-lisp @ MIT-OZ
dumper was trying to send this, but didn't know who to send it to. to
tell it, create a file called DIRECTORY.OWNER. which contains the name
of someone responsible for the dir; then dumper will send to that
person.
----------
Date: 11 Apr 1983 0538-EST
From: The Mailer Daemon <Mailer@MIT-OZ>
To: <TU77-MAN@MIT-OZ>
Subject: Message of 11-Apr-83 05:35:32
Message failed for the following:
LIBLSP@MIT-OZ: No such mailbox
------------
Date: 11-Apr-83 05:35:32
From: DUMPER
To: LIBLSP
Subject: Migrated files
The following files have been migrated:
PS:<LIBLSP>APROPOS.FASL.1
-------
∂13-Apr-83 2209 Dave Touretzky at CMU-CS-A CMU MacLisp broken
Received: from USC-ECL by SU-AI with NCP/FTP; 13 Apr 83 22:08:37 PST
Received: from MIT-MC by USC-ECL; Wed 13 Apr 83 22:05:22-PST
Date: 14 April 1983 0101-EST
From: Dave Touretzky at CMU-CS-A
To: bug-lisp at MIT-MC
Subject: CMU MacLisp broken
CC: Scott Fahlman <FAHLMAN at CMU-CS-C>,
Leonard Zubkoff <Zubkoff at CMU-CS-C>,
Neal Feinberg <feinberg at CMU-CS-C>, Richard Goldschmidt at CMU-CS-A
CMU recently, with no prior warning, changed the name of its primary TOPS-10
machine from CMU10A to CMUCSA. As a result, MacLisp no longer recognizes us
as a CMU site: (STATUS OPSYSTEM-TYPE) returns TOPS-10 instead of CMU. This
has in turn broken some of the code in the CMU MacLisp programming
environment.
I traced the problem to two lines of code a couple of screenfuls past the
label D10SET. The solution is to replace the string "CMU10" with the string
"CMUCS" where it appears on those two lines.
Would somebody like to make the change in the sources?
-- Dave Touretzky
∂17-Apr-83 1349 PASIEKA@MIT-OZ Pretty-Printer
Received: from USC-ECL by SU-AI with NCP/FTP; 17 Apr 83 13:49:22 PST
Received: from MIT-MC by USC-ECL; Sun 17 Apr 83 13:48:04-PST
Date: Sun, 17 Apr 1983 14:43 EST
From: PASIEKA@MIT-OZ
To: INFO-MACLISP@MIT-OZ
Subject: Pretty-Printer
I am trying to use the gobble code found in ksb on ml. In
trying to do this I have come up against the problem of transporting
the code to oz and making it work with the various hooks to pretty
print the objects created by the gobble functions. This has problems
when I try to move the code from the format directory on ml to oz.
Does anyone know if it is possible to transport this system to oz and
would they be willing to give me some help in doing so?
Thanks.
-- Mike
∂18-Apr-83 2004 WILLIS@MIT-ML
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 20:04:34 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 20:04:22-PST
From: WILLIS@MIT-ML
Date: 04/18/83 23:04:55
WILLIS@MIT-ML 04/18/83 23:04:55
To: (BUG LISP) at MIT-ML
CC: WILLIS at MIT-ML
I have been trying for some time to print out text files on a printer
connected to my ADDS Viewpoint terminal.
At the cost of great pain and agony I managed (I think) to write a tiny
LISP program to send a file to the terminal without using the ITS PRINT
utility, since this does various things intended for the terminal which
foul up the printer output.
Imagine my shock and horror to find that (apparently) even the tyo subr
goes via CRTSTY, and therefore does annoying things like outputting
spaces (ASCII 32.) as cursor control characters.
Is there a LISP subr which sends absolutely nothing but the given ASCII
code to my modem? Alternatively, is there a system variable which I
can reset to make the system think (temporarily) that I have a totally
dumb terminal?
∂18-Apr-83 2117 Kent M. Pitman <kmp at MIT-MC> WILLIS@ML's TYO gripe
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 21:17:51 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 21:17:05-PST
Date: Tuesday, 19 April 1983, 00:08-EST
From: Kent M. Pitman <kmp at MIT-MC>
Subject: WILLIS@ML's TYO gripe
To: bug-lisp at mc
I sent him a note suggesting he look into IMAGE mode I/O.
∂18-Apr-83 2129 Alan Bawden <ALAN @ MIT-MC> IMAGE mode IO
Received: from USC-ECL by SU-AI with NCP/FTP; 18 Apr 83 21:29:38 PST
Received: from MIT-MC by USC-ECL; Mon 18 Apr 83 21:25:43-PST
Date: 19 April 1983 00:17 EST
From: Alan Bawden <ALAN @ MIT-MC>
Subject: IMAGE mode IO
To: WILLIS @ MIT-ML
cc: BUG-LISP @ MIT-ML
In-reply-to: Msg of 04/18/83 23:04:55 from WILLIS at MIT-ML
Well, its a real feature of ITS that the system always presents programs
with a virtual terminal so that they don't have to know the peculiarities
of the user's actual terminal. LISP is no exception to thiv@∞@≠∀≠M9$4)$4)4(4)94)%QL4)QQd%5¬≥∀%4)QQd4)→1%M@αode by doing:
(OPEN '|TTY:| '(OUT TTY IMAGE))
This form returns a file-object. Save that file-object and pass it to the
TYO function as a second argument. Then whatever you passed as the first
argument, should be sent directly to your device..
∂11-May-83 0928 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 09:26:56 PDT
Received: from MIT-MC by USC-ECL; Tue 10 May 83 23:04:47-PDT
Date: Wednesday, 11 May 1983, 01:58-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
Subject: LOOP CONTINUE STATEMENT
To: bug-LISPM@MIT-OZ, LISP-FORUM@MIT-OZ, dove@MIT-DSPG
In-reply-to: The message of 14 Apr 83 10:14-EST from Webster Dove <dove at MIT-DSPG>
I'd also be very interested in hearing answers to the following question:
Return-path: <dove@MIT-DSPG>
Date: Thursday, 14 April 1983, 10:14-EST
From: Webster Dove <dove at MIT-DSPG>
To: info-LISPM at MIT-OZ
Is there a way in (loop ...) to say
"go directly to the next iteration. Do not execute the remaining
clauses of the body"
Such statements typically are called "continue" or "next"
I have encountered many situations where such a statement would be
useful.
∂11-May-83 0931 @USC-ECL,@MIT-MC:MOON@SCRC-TENEX LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 09:29:48 PDT
Received: from MIT-MC by USC-ECL; Wed 11 May 83 00:03:00-PDT
Date: Wednesday, 11 May 1983 02:43-EDT
From: MOON at SCRC-TENEX
To: Matt BenDaniel <SMATT at MIT-OZ>
Cc: bug-LISPM at MIT-OZ, dove at MIT-DSPG, LISP-FORUM at MIT-OZ
Subject: LOOP CONTINUE STATEMENT
In-reply-to: The message of 11 May 1983 01:58-EDT from Matt BenDaniel <SMATT@MIT-OZ>
Date: Wednesday, 11 May 1983, 01:58-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
I'd also be very interested in hearing answers to the following question:
Date: Thursday, 14 April 1983, 10:14-EST
From: Webster Dove <dove at MIT-DSPG>
Is there a way in (loop ...) to say
"go directly to the next iteration. Do not execute the remaining
clauses of the body"
Such statements typically are called "continue" or "next"
I have encountered many situations where such a statement would be
useful.
Date: Thursday, 14 April 1983 17:27-EST
From: MOON at SCRC-TENEX
In-reply-to: The message of 14 Apr 1983 10:14-EST from Webster Dove <dove at MIT-DSPG>
There isn't now. Normally one encloses the body in a conditional
(unfortunately, it can be painful to do this currently if the body
includes COLLECT statements). The main problem with having a continue
statement is that it may be unclear just what is regarded as "the body"
and what is regarded as "the iteration framework": If there is a WHILE
statement later in the LOOP than the CONTINUE, should it be skipped
or should it still be executed? And is the answer to this affected by
whether there is a DO after the WHILE?
∂11-May-83 1022 @USC-ECL,@MIT-MC:SMATT@MIT-OZ LOOP CONTINUE STATEMENT
Received: from USC-ECL by SU-AI with TCP/SMTP; 11 May 83 10:21:33 PDT
Received: from MIT-MC by USC-ECL; Wed 11 May 83 00:29:53-PDT
Date: Wednesday, 11 May 1983, 03:25-EDT
From: Matt BenDaniel <SMATT@MIT-OZ>
Subject: LOOP CONTINUE STATEMENT
To: MOON@SCRC-TENEX, SMATT@MIT-OZ
Cc: bug-LISPM@MIT-OZ, dove@MIT-DSPG, LISP-FORUM@MIT-OZ
In-reply-to: The message of 11 May 83 02:43-EDT from MOON at SCRC-TENEX
A CONTINUE statement should mean skipping executing any code lexically
after it on the current iteration. This could, of course, be a problem
in the following:
. . . (loop for x = 0 then (1+ x)
IF (> x 3)
CONTINUE
until (> x 7))
However, this is the problem of the coder. If there are other reasons
why implementing (or specifying) the function of a CONTINUE statement,
how about constraining the location of an IF-CONTINUE sequence in a
LOOP body in a manner similar to the IF-DO sequence, where iteration is
not allowed to follow body code. Also, what about a CONTINUE-NAMED
feature for NAMED loops?
∂14-May-83 1416 @USC-ECL,@MIT-MC:KMP@MIT-OZ <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 May 83 14:16:37 PDT
Received: from MIT-MC by USC-ECL; Sat 14 May 83 14:13:40-PDT
Date: Sat, 14 May 1983 17:01 EDT
From: KMP@MIT-OZ
To: BUG-LISP@MIT-OZ
cc: PHW@MIT-OZ
Subject: <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
PHW tried to use my TTY package (containing DO-WITH-TTY-ON,
DO-WITH-TTY-OFF, etc) and found it broken because the FASL file
was trying to INCLUDE LISP:SUBLOAD. The reason it was trying to
do this was to get around some hassle with SI:GEN-LOCAL-VARIABLE,
which JONL had patched the source to use in place of GENSYM.
The reason the INCLUDE happened at the wrong time was because
someone wrote (IF (STATUS FEATURE ITS) (INCLUDE ...) (INCLUDE ...))
instead of (INCLUDEF (IF ...)).
The macros in this file are the sort that other macros do not expand
into. They are the kind of thing which programs expand into and as
such, with the exception of a few cases of "#%", GENSYM is completely
reasonable and has no problems about it.
In any case, I have seen far too many bugs caused by the fact that
these things do not primitively autoload and I don't think it's worth
using either GENTEMP or SI:GEN-LOCAL-VARIABLE unless they become primitively
available. They are inappropriate for use in libraries which are not
maintained as an essential feature of the system until they are primitively
accessible.
I would appreciate if people would refrain from adding stupid little
"features" like this to my libraries without at least telling me that
they have done so and without checking that the "features" work. I tend
to check the software I release relatively carefully and this sort of
thing gives my software a bad name. In this case, the FASL file wouldn't
even LOAD so it's quite clear that no one had tested it.
I wrote OZ:PS:<LIBLSP>TTY.LSP.24 and compiled it. It seems to work fine.
Please report bugs.
By the way, this version also includes another macro called BIND-TTYINT
which allows a let-style syntax for binding TTYINT things. eg,
(BIND-TTYINT ((#↑B NIL) (#↑H #↑B)) ...body...)
binds ↑B to no interrupt and Backspace to work like ↑B for the invocation
of the BODY.
I'll copy this back to ITS later today in case anyone finds it easier to
pick up the new versions from there than from here.
--kmp
∂14-May-83 1632 @USC-ECL:KMP@MIT-MC
Received: from USC-ECL by SU-AI with TCP/SMTP; 14 May 83 16:32:17 PDT
Received: from MIT-MC by USC-ECL; Sat 14 May 83 15:19:58-PDT
Date: 14 May 1983 18:17 EDT
From: Kent M. Pitman <KMP @ MIT-MC>
To: INFO-MACLISP @ MIT-MC
I added a macro called BIND-TTYINT to the TTY package on LIBLSP.
It binds the TTYINT status of one or more characters within a given
dynamic scope. Sample calling sequence is
(BIND-TTYINT ((#↑B NIL) ;disable control-B
(#↑↑ #↑G) ;make control-↑ like control-G
(#↑H #'FOO)) ;make control-H (Backspace) handled by function FOO
...body...)
To get these fixes outside of MIT, Lisp maintainers need to pick up
version 24 of ((LIBLSP) TTY).
--kmp
∂15-May-83 0920 @USC-ECL,@MIT-MC:GJC@MIT-MC <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
Received: from USC-ECL by SU-AI with TCP/SMTP; 15 May 83 09:11:15 PDT
Received: from MIT-MC by USC-ECL; Sun 15 May 83 09:06:28-PDT
Date: 15 May 1983 12:02 EDT
From: George J. Carrette <GJC @ MIT-MC>
Subject: <LIBLSP>TTY.LSP.24 fixes bugs in <LIBLSP>TTY.KMP.20
To: KMP @ MIT-OZ
cc: BUG-LISP @ MIT-OZ, PHW @ MIT-OZ
In-reply-to: Msg of Sat 14 May 1983 17:01 EDT from KMP at MIT-OZ
I could have sworn that I diked out the SUBLOAD and SI:GENTEMP stuff
from TTY a while ago. Indeed, check out LIBDOC;TTY 19, which was
written in NOV '82. At least the FASL for this was moved to OZ also,
when I found I got screwed by missing autoload files. Evidently the OZ
version was further hacked later on by someone else, reintroducing the
lossage. Blame me for not moving the source to OZ also.
N.B. All those who would hack Maclisp on OZ: The sources to Maclisp have
not ever been considered to be on OZ. The software was installed by
"helpful" outsiders before responsible local maclisp hackers could act.
Since then it has been fun to watch. Kent, if it weren't for people like
you fixing up things maybe we could have the total collapse that would
lead to a fresh start though?
-gjc
∂26-May-83 2214 @USC-ECL,@MIT-MC:ALAN@MIT-OZ Yuch!
Received: from USC-ECL by SU-AI with TCP/SMTP; 26 May 83 22:14:27 PDT
Received: from MIT-MC by USC-ECL; Thu 26 May 83 22:11:40-PDT
Date: Fri, 27 May 1983 01:08 EDT
From: Alan Bawden <ALAN@MIT-OZ>
To: bug-lisp@MIT-OZ
Subject:Yuch!
I just discovered that the setting of the MAKHUNK switch controls TWO
things at once. Setting it to T makes (makhunk 2) return a hunk (which I
like), and it also makes '(1 . 2 .) return a hunk (which I think sucks, I
would much prefer to get a dot context error). Yuch!
∂04-Jun-83 1636 @USC-ECL,@MIT-MC:SAZ@MIT-OZ binding 't to other things (like nil)
Received: from USC-ECL by SU-AI with TCP/SMTP; 4 Jun 83 16:36:46 PDT
Received: from MIT-MC by USC-ECL; Sat 4 Jun 83 16:35:45-PDT
Date: Saturday, 4 June 1983, 19:32-EDT
From: David M. J. Saslav <SAZ@MIT-OZ>
Subject: binding 't to other things (like nil)
To: bug-lisp@MIT-OZ
I don't think it's a good idea to be able to say (setq 't ni), since this makes forms like
(cond (t 45) (nil 50) ((print "me") 100)) return:
ME
100